A storage system is a computer that provides storage service relating to the organization of information on writable persistent storage devices, such as memories, tapes or disks. The storage system is commonly deployed within a storage area network (SAN) or a network attached storage (NAS) environment. When used within a NAS environment, the storage system may be embodied as a file server including an operating system that implements a file system to logically organize the information as a hierarchical structure of data containers, such as directories and files on, e.g., the disks. When used within a SAN environment, the storage system may organize the information in the form of databases or files. Where the information is organized as files, the client requesting the information typically maintains file mappings and manages file semantics, while its requests (and system responses) address the information in terms of block addressing on disk using, e.g., a logical unit number.
Each “on-disk” file may be implemented as set of data structures, i.e., disk blocks, configured to store information, such as the actual data for the file. These data blocks are typically organized within a volume block number (vbn) space that is maintained by the file system. The file system may also assign each data block in the file a corresponding “file offset” or file block number (fbn) position in the file. The file system typically assigns sequences of fbns on a per-file basis, whereas vbns are assigned over a larger volume address space. That is, the file system organizes the data blocks within the vbn space as a volume; each volume may be, although is not necessarily, associated with its own file system. The file system typically consists of a contiguous range of vbns from zero to n, for a file system of size n−1 blocks.
The storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many clients to access files stored on the system. In this model, the client may comprise an application, such as a database application, executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet. The client typically communicates with the storage system by exchanging discrete frames or packets of data according to pre-defined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP). In addition, the client may request the services of the system by issuing file system protocol messages over the network to the storage system.
A file system may have the capability to generate a snapshot of its active file system. An “active file system” is a file system to which data can be both written and read, or, more generally, an active store that responds to both read and write operations. The snapshot is another form of a data container that refers to a copy of file system data that diverges from the active file system over time as the active file system is modified. Snapshots are well-known and described in U.S. patent application Ser. No. 09/932,578 entitled Instant Snapshot by Blake Lewis et al., now issued as U.S. Pat. No. 7,454,445 on Nov. 18, 2008, TR3002 File System Design for a NFS File Server Appliance by David Hitz et al., published by Network Appliance, Inc. and in U.S. Pat. No. 5,819,292 entitled Method for Maintaining Consistent States of a File System and For Creating User-Accessible Read-Only Copies of a File System, by David Hitz et al., each of which is hereby incorporated by reference as though fully set forth herein.
A known file system implementation provides snapshots through “copy out” or “copy on write” operations. When updating a block with new file system data, the file system reads the data block from a previous (old) location on disk and writes that block to a new location prior to writing the updated block in-place at the old location. The active version of the file system thus remains contiguous and maintains its same layout on disk, while the snapshot versions are copied out and moved around on disk. However, a problem with the known copy-on-write operation implementation is that it renders each write operation expensive because of the amount of work that has to be performed for each operation, e.g., read the old data block, find a new location for the old data, store the old data in the new location and store the updated data in the old location.